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TRY BEFORE YOU BUY SOFTWARE; 
DISTRIBUTION AND MARKETING SYSTEM 



FIELD OF THE INVENTION 
The present invention relates to a system and 
method for gathering data related to usage of software 
programs sampled by a potential purchaser or other user of 
the programs . 

10 BACKGROUND OF THE INVENTION 

Customers or potential purchasers of software 
programs often desire to test the programs before 
determining whether or not to purchase them. This may 
occur because written literature does not adequately 

15 provide the customer with a feel for the functionality of 
the software program when in operation. The written 
literature simply describes the program, and customers 
often want to actually work with the software program in 
order to determine if they want to buy the program. 

20 Some software vendors provide demonstration 

programs of their software programs for sale. These 
demonstration programs are not the fully operating version 
of the software program. The demonstration program simply 
contains some of the functionality of the full software 

25 program in order to provide the customer with a feel for 
the functionality of the program. Since the demonstration 
version is not a fully operating version of the program, 
however, it does not provide a customer with a complete 
picture of the program's functionality. Therefore, 

3 0 demonstration versions are limited in how they may assist a 
customer in deciding whether to purchase a particular 
software program. 

Recently, some software vendors are providing 
fully operating versions of software programs which a 

35 customer may sample. These software programs are intended 
to be securely stored on a particular storage medium. 
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Therefore, when a customer samples a fully operating 
version of a program, the program being sampled is securely 
maintained by another program which seeks to prevent the 
customer from obtaining a free copy of the sampled program. 



programs to be sampled on some type of transportable 
storage medium. For example, a software vendor may provide 
a floppy diskette on which is contained the program to be 
sampled. The diskette may be locked due to changes to the 

10 physical storage medium such that the customer may not 

obtain a free copy of the program. Other software vendors 
provide a CD-ROM which stores a large number of programs 
which may be sampled. The CD-ROM also contains a program 
which manages and in effect supervises the sampling of the 

15 programs such that a customer may not obtain copies of the 
programs without first purchasing them and obtaining 
particular unlocking codes. 



operating versions of programs, however, are generally 
20 limited in that they do not provide for on-line 

distribution. These systems typically distribute the 
programs on some type of transportable storage medium, such 
as a CD-ROM or hard disk drive sold with a computer. This 
type of distribution can be more burdensome to the computer 
25 user, because an on-line distribution channel is more 
easily accessible, since the computer users need simply 
"dial up" a network or bulletin board. 



operating versions of programs are also limited in the 
3 0 security provided to the programs being sampled. For 
example, they typically prevent unauthorized copying of 
programs by dividing the program or removing portions of 
the program such that a secure "key" is required to 
reassemble the program and thus operate it. These methods, 
35 however, require that one tamper with the program, which 
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can make the program unstable. In addition, these methods 
typically do not work with all applications. For example, 
some applications use a checksum program to prevent damage 
from computer viruses. These distribution methods change 
5 the format of the program, which can result in the checksum 
virus check incorrectly returning a error or message that 
the program is corrupted. 

SUMMARY OF THE INVENTION 

10 This invention is a system and method for 

demonstrating software programs to a potential purchaser of 
the programs and for gathering marketing information 
related to the demonstration of the programs. The system 
receives a plurality of software programs to be 

15 demonstrated and maintains each of the software programs in 
a locked state in order to prevent unauthorized duplication 
of the software programs. 

Any of the software programs are enabled for 
execution upon selection by a user, and the user is allowed 

20 to subsequently operate or sample the selected software 
program. The system maintains the selected software 
program in the locked state during the sampling in order to 
prevent unauthorized duplication of the selected software 
program. The sampling of the selected software program is 

25 selectively disabled, such as when the user completes the 
sampling or if the system detects that the user is 
attempting to copy the sampled application. 

In addition, a code is generated that identifies 
a particular software program in the plurality of software 

3 0 programs and contains information relating to sampling of 
the particular software program by the user, such as which 
applications were sampled and how many times they were 
sampled. 

35 BRIEF DESCRIPTION OF THE DRAWINGS 
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FIG. 1 is a diagram of the conceptual operation 
of a software or digital information distribution system. 

FIG. 2 is a block diagram of hardware components 
for implementing a software or digital information 
5 distribution system. 

FIG. 3 is a user interface for a software or 
digital information distribution system illustrating 
examples of programs available to be sampled and/or 
purchased. 

10 FIG. 4A is a diagram of software program files 

used by a software or digital information distribution 
system. 

FIGS. 4B and 4C are diagrams of a package file 
system for use in maintaining software programs or digital 
15 information in a locked state. 

FIG. 5 is a diagram of background processes used 
by a software or digital information distribution system. 

FIG. 6 is a flow chart of a preferred active 
process detection routine. 
2 0 FIG. 7 is a flow chart of a preferred background 

processing setup routine. 

FIG. 8 is a flow chart of a preferred check 
status of sample count files routine. 

FIG. 9 is a flow chart of a preferred "do open" 

25 routine. 

FIG. 10 is a flow chart of a preferred "do prime" 

routine . 

FIG. 11 is a flow chart of a preferred image 
driver routine. 

30 FIG. 12 is a flow chart of a preferred install 

active process detection code routine. 

FIG. 13 is a flow chart of a preferred install 
image driver routine. 

FIG. 14 is a flow chart of a preferred open 
35 driver routine. 
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FIG. 15 is a flow chart of a preferred sample 
count manager routine. 

FIG. 16A is a flow chart of a preferred sector 
encryption/decryption routine. 
5 FIG. 16B is a flow chart of a preferred varying 

positional key encryption/decryption routine used with the 
routine of FIG. 16A. 

FIG. 17 is a flow chart of a preferred setup 
sample counter routine. 
10 FIG. 18 is a flow chart of a preferred watchdog 

task routine. 

FIG. 19 is a flow chart of a preferred purchase 
routine for allowing users to purchase sampled software 
programs . 

15 FIG. 20 is a flow chart of a preferred process 

for a self -launching and on-line self -launching software or 
digital information distribution system. 

FIG. 21 is a flow chart of a preferred process 
for generating a serial number which contains 
20 identification of marketing information for sampled 
software programs . 

FIG. 22 is a flow chart of a preferred process 
for automatic sale of software programs. 

25 DETAILED DESCRIPTION 

FIG. 1 is a conceptual diagram of the operation 
of a software or digital information distribution system. 
A user or customer 10 may sample a software program 12, 
which typically involves working with a fully operating 

3 0 version of the software program 12. The system preferably 
maintains a secure interface or protective envelope 14 
around the software program 12 such that the user 10 may 
not obtain a copy of the software program without first 
purchasing it. The system preferably maintains the sampled 

35 program in a locked state during the sampling of the 




program in order to prevent unauthorized duplication of the 
program, for example, during the sampling. The system 
selectively disables the sampling of the selected software 
program, such as when the user completes the sampling or 
5 tampers with the program during the sampling. The use of a 
secure interface or protective envelope 14 provides the 
advantage of not tampering with the program for security 
purposes. This type of scheme for maintaining a program in 
a locked state is described below. Other methods for 

10 maintaining software programs in a locked state to prevent 
unauthorized copying of the program are possible, such as 
is disclosed in U.S. Patent Nos . 4,658,093; 4,740,890; 
4,999,806; and 5,341,429. 

If the user 10 purchases the software program 12, 

15 then the system copies an unlocked copy of the software 
program 16 to a storage medium where the user may access 
and continue to use the program. "Software program," 
"program, n and "application, " are used interchangeably 
herein. 

20 The present invention can also distribute digital 

information (12), as indicated in FIG. 1. The present 
invention views the distributed entity as "bits," whether 
it is a software program which includes functionality for 
controlling the operation of a computer, or simply other 

25 types of information in digital form. Therefore, the 

principles of the present invention used for distribution 
of information apply to digital information generally, 
software programs being a type of digital information. 
Digital information includes information capable of being 

3 0 represented in digital form. Digital information thus 

includes software programs and also includes intellectual 
property such as data representing creative or artist 
expression. Other examples of digital information include: 
textual works such as books and articles; music; video; 

35 music video; fonts; graphics; and clip art. 
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In distributing digital information, a user may- 
have the option to sample the information. For example, 
when distributing locked movies in digital form, a user may 
be allowed to view the first few minutes of the movie. For 
5 distributing music, a user may be allowed to sample a 
representative portion of the music. If the digital 
information is a software program, the user may be allowed 
to sample the program, as mentioned above. 

The digital information may also be distributed 

10 without sample capability. For example, a publisher may 

distribute a CD-ROM having several locked "white papers" or 
technical works. The system can, for example, only display 
titles or abstracts to a user for purposes of allowing the^ 
user to decide which if any textual works to purchase. 

15 When a user requests to purchase one or more of the papers, 
the system unlocks the paper and distributes it to the 
user. This distribution scheme thus provides the advantage 
of allowing one to purchase individual textual works in a 
collection without having^purchase the entire compilation. 

2 0 The system, therefore, maintains the digital 

information in a locked state by using the secure interface 
or protective envelope 14. When a user requests to 
purchase the information and provides any required 
information such as a credit card number, the system 
25 distributes an unlocked copy (16) of the digital 
information to the user. 

FIG. 2 is a diagram of typical hardware 
components for implementing a software or digital 
information distribution system. The system includes a 

3 0 computer 18 which is a typical digital computer such as a 

personal computer. The computer 18 includes a 
microprocessor 20 for executing software programs. The 
microprocessor 2 0 is interfaced with a read only memory 22 
and random access memory 24. The computer 18 is interfaced 
3 5 with an input device 26 for entering commands or 




information into the computer 18. The input device 26 may- 
be implemented with, for example, a keyboard, touch screen, 
light pen, "mouse" or other cursor control device such as a 
trackball, or other device for entering information or 
5 commands into the computer 18. The computer 18 is 
typically interfaced with a printer 28, which may be 
implemented with a typical computer printer for generating 
a hard copy of the information stored within the computer 
18. The computer 18 is also typically interfaced with a 
10 display device 30, which may be implemented with a typical 
color or monochrome computer monitor. A preferred hardware 
platform for implementing the present invention is a 
Macintosh computer, developed and sold by Apple Computer, 
Inc . 

15 The computer 18 is also preferably interfaced to 

devices from which it may receive software programs to be 
sampled optionally along with a software program for 
managing the sampling of additional software programs. 
These external devices may include a digital audiotape 

20 drive 32, disk drive 34, hard disk drive 36, CD-ROM drive 

38, or an on-line system 42 interfaced through a modem 40. 

The on-line system 42 may be interfaced to existing 

networks or on-line services such as, for example, the 

® ® 
Internet, America OnLine , and Prodigy . Computer users 

25 may download information from networks such as the 

Internet . 

FIG. 3 is a user interface of a software or 
digital information distribution system operating within 
the computer 18 by the microprocessor 20. User interface 

3 0 50 displays in window 44 a plurality of programs which a 
user may sample and/or purchase. Alternatively, window 44 
can display an identification of digital information 
available for purchase. In order to sample a particular 
program, a user would select one of the plurality of 

35 programs in window 44 and then select icon 46. In 



addition, the system allows a user to select other 
information identified in window 52, and that information 
is displayed in window 51, such as: program information; 
system requirements; information about "getting started" 
5 with a particular application; publisher information; 
licensing agreement; and packaging photos. 

If the user desires to purchase one of the 
programs, a user would select the purchase icon 48 and 
optionally the install icon 47 in order to have the program 

10 automatically installed. When a user samples a particular 
program, the system preferably displays the number of 
samples remaining at location 49 and optionally additional 
information such as the version of the sampled program. As 
explained below, the system can thus control how many 

15 samples are available to the user. FIG. 3 is one example 
of user interfaces for a software or digital information 
distribution system. Other user interfaces or ways of 
allowing a user to interact with the system are possible 
for such a system. 

20 FIG. 4A is a diagram of files used by a software 

or digital information distribution system. An example of 
a software or digital information distribution system is 
also referred to as a "distribution application" in the 
present specification. The system typically uses an image 

25 driver 56 and invisible files 60. FIG. 4A also illustrates 
how a software or digital information distribution system 
may be implemented in a separate "stand-alone" version and 
a self -launching version. In one embodiment, the system 58 
is a separate software program which interfaces an 

3 0 encrypted package 62 containing a usage file 64 and a 

program or digital information 66 to be distributed and/or 
sampled. The usage file 64 typically contains a separate 
redundant copy of how the program or digital information is 
to be used; for example, how many samples are available. 

35 This is in addition to the invisible files, which store 



encrypted copies of how many samples are available, as 
explained below. Accordingly, the usage file 64 provides 
another level of protection in the event that a user 
tampers with or otherwise alters the sample count 
5 information in the invisible files. The software program 
or digital information is preferably encrypted, as 
explained below, in order to prevent a user from obtaining 
a "free" copy of the information. 

In another embodiment, a self -launching system 

10 implementing a software or digital information distribution 
system 72 is attached to a usage file 70 and program or 
digital information 74 to be distributed and/or sampled. 
In this embodiment, distribution application is attached to 
each program or information to be distributed and/or 

15 sampled and its operation is thus essentially invisible to 
the user. Therefore, instead of requiring a user to 
install a software or digital information distribution 
system and then sample other software programs, a user may 
simply download each program to be sampled and/or 

2 0 purchased. Each of those packages contains a distribution 

application for controlling the sampling or distribution of 
software programs or digital information along with such 
programs or information. 

The distribution application 72 is typically 
25 attached to the encrypted package by joining the 

distribution application stored in a resource fork and the 
encrypted package stored in the data fork into one file 71. 
The operation of the resource fork for storing structured 
data and the data fork for storing random access data in a 

3 0 Macintosh computer system is well known. Therefore, the 

file 71 includes the distribution application 72 "wrapped 
around" the encrypted package 68 which includes an 
encrypted application or digital information 74 along with 
the encrypted usage file 70. The distribution application 
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72 also contains the invisible files. The package 68 is 
typically encrypted in the same manner as package 62. 

As mentioned above, applications used by a 
software or digital information distribution system are 
5 maintained in a locked state. This locked state is used to 
prevent unauthorized copying of the program both while it 
is stored and when a user samples it. The applications to 
be sampled are typically in a form only usable by a 
software or digital information distribution system in 

10 order to ensure security. Encryption as part of a locked 
state is typically accomplished by exclusive-ORing 
("XORing" ) each byte of the application with a positional 
variant, as is explained with reference to FIGS. 16A and 
16B. In addition, a package file system is also typically 

15 used as a part of a locked state to ensure security of the 
applications in a locked state. 

This package file system is illustrated in FIGS. 
4B and 4C. As shown in FIG. 4B, a package file in a 
Macintosh computer system works much like a random access 

20 memory (RAM) disk except that it is in non-volatile memory. 
An image file 77 which is the desired size of a "virtual 
volume" created by a software or digital information 
distribution system is allocated on a hard drive 75 or 
other non- volatile storage medium. Locked applications or 

25 digital information are stored within this partition. In a 
self -launching distribution application, the distribution 
application and image file appear as one file 67. A 
distribution application file 73 is also stored on the 
storage medium 75. 

30 As shown in FIG. 4C, the image file 77, or in the 

self -launching case the distribution application/image file 
67, is internally given the same structure as a floppy 
disk. A distribution application 69 then informs the 
operating system of the corresponding computer that a 

35 "floppy disk" 79 is actually mounted. The operating system 
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of a computer system 81 sends read/write requests 85 to the 
virtual volume 79. Instead of writing to a physical media, 
the driver of the computer's operating system writes to the 
virtual volume 79. The image driver 83 of the distribution 
5 application 69 performs reading and writing to the image 
files 77 and 67. This technique is also known as a "soft 
partition, " because the hard drive on which the image file 
is located has been effectively partitioned via software. 
Accordingly, a distribution application 69 can reserve this 

10 virtual volume in order to control reading and writing to 
this partition (the physical media) and thus prevent 
unauthorized copying of appli cation s or digital information 
in this partition. 

FIG. 5 is a diagram of background processes used 

15 by a software or digital information distribution system 
implemented within the computer 18 and executed by the 
microprocessor 20. The background processes preferably 
include an active process detection 76, image driver 78, 
sample count manager 80, sector encryption/decryption 82, 

20 and watchdog task 84, all of which are described below. 

FIG. 6 is a flow chart of an active process 
detection routine. On an exemplary embodiment on a 
Macintosh computer, this routine is implemented by a patch 
to the system trap called SystemTask. This trap is called 

25 consistently by all applications many times a second. What 
makes this work is that the Finder intercepts calls to 
SystemTask, and only passes on the call of the application 
that is the "active" or current " front -most " process. 
Therefore, when a patch to SystemTask is called, the system 

30 assumes that the front application called it. The system 
then checks the low level variable AppName to retrieve the 
name of the current front -most application. 

In a windows or multi- tasking environment, 
several applications can be represented by windows which 

35 may overlap. A currently-active application is typically 




represented in a window which appears in front of the other 
windows, or is otherwise highlighted or altered to indicate 
that it is the currently-active program if, for example, 
the displayed windows are not overlapping. 
5 The routine begins when the system task was 

called (86) . The system retrieves the front -most 
application name (88) and determines if the sample program 
is in front (90) . The sample program is the software 
program being sampled by the user. The system determines 

10 if this is the top-most or front-most program displayed on 
a user's monitor. If it is the application in front, the 
system determines if sample time limit has expired (92) ; 
otherwise, the system determines if a distribution 
application is in front (94) . A time limit provides for 

15 additional security by limiting how long a user may sample 

a particular application. If the time limit has expired, 
f A 

the system sets a flag to enable the image driver (100) and 

calls the original system task (108) . Otherwise, if the 

A sample time limit has np£ expired, the system terminates 

2 0 the sample application (98) . 

If as determined at step 94 the sample 
application is in front, the system sets a flag to enable 
the image driver (96) ; otherwise, a flag is set to disable 
the image driver (102) . Next, the system determines if the 
25 sample application file is still open (104) . If it is not, 
the system closes and unmounts the virtual volume (106) and 
calls the original SystemTask (108) . 

The routine of monitoring which application is 
"in front" thus provides a security measure by preventing 

3 0 the unauthorized copying of an application while it is 

being sampled. This system for preventing unauthorized 
duplication of a particular software program among a 
plurality of active software programs executed on a 
computer typically includes the following features. It 
3 5 receives an indication that the computer is executing the 




particular software program, and monitors operation of the 
computer to determine which of the plurality of the active 
software programs is being currently executed. Execution 
of the particular software program is disabled when the 
5 monitoring determines that the particular software program 
is not the currently-active or top-most software program. 

FIG. 7 is a flow chart of a background processing 
setup routine. In this routine, the system decrypts and 
installs a background processing code (110) ; initializes 

10 the global variables (112) ; installs a watchdog task (114) 
(see FIG. 18) ; installs active process detection code (116) 
(see FIG. 12) ; sets up a sample counter (118) (see FIG. 
17) ; sets up interprocess communication vectors (120) ; and 
installs an image driver (122) (see FIG. 13) . 

15 FIG. 8 is a flow chart of a check status of 

sample count files routine. The system preferably uses 
sample count files stored within the computer 18 as 
invisible files. These sample count files are preferably 
each identical and maintain the sample count. Each file 

20 typically contains an identification of each application 
and the number of allowed samples for each of the 
applications. If the user attempts to tamper with a 
particular sample count file in order to obtain more 
samples, the system detects that tampering by comparing the 

25 tampered file with the other sample count files. In 

addition, the invisible files are preferably encrypted for 
additional security, such as using an XOR operation with a 
key and a bit shift of the sample counts. 

In this routine, the system determines at steps 

30 124, 128, and 132 if the sample count files one, two, and 
three, respectively, have been created. If the sample 
count files have not been created, the system creates the 
corresponding sample count files at steps 126, 130 and 134. 
While the system uses three sample count files, more or 

35 fewer files may be used. 
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FIG. 9 is a flow chart of a "do open" routine. 
The system first retrieves the address of "OK to Read" flag 
from a background code via interprocess communication 
(13 6) . Next, the system retrieves the address of a sector 
5 decryption routine from the background code via 

interprocess communication (138) and sets standard open 
flags (140) . 

FIG. 10 is a flow chart of a "do prime" routine. 
The system first determines if this is read call (142) . 

10 This test makes the driver read only. If this is not a 
read call, the system returns an error (154) . Otherwise, 
the system proceeds with the routine and retrieves a value 
of a flag in the background process (144) . It is next 
determined if the flag value has been updated within the 

15 last two seconds (146), for example. A flag is stored in 
the background process that is constantly updated by the 
watchdog task. If the flag has not been updated in the 
last two seconds, for example, it means that either a valid 
application is not "in front" (the sample application or 

20 distribution application) as explained above, or that a 
user is using a debugger to examine the code which 
implements the system. If the flag value has been updated 
in the last two seconds, the system reads requested sectors 
from "virtual" volume (150) and returns no error (152) . 

25 The system decrypts the sectors while reading 

them. The encryption/decryption of sector is explained 
with reference to FIGS. 16A and 16B. If the sectors of the 
application are compressed, the system also decompresses 
the sectors while reading them. An example of an 

3 0 asymmetrical compression/decompression algorithm, which 
produces a relatively short decompression time in 
comparison to compression time, is Apple Computer, Inc . ' s 
Cinepak compression scheme at a lossless level. If the 
flag value has not been updated, the system determines if 

35 this is a directory or volume information block (148) . If 
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it is, the system executes step 150 and returns no error 
(152) . Otherwise, the system returns an error (154) . 

FIG. 11 is a flow chart of an image driver 
routine. The image driver preferably includes the 
5 following functions: open call (156); prime call (160); 
control call (164) ; status call (168) ; and close call 
(172) . If any of these functions have been called, then 
the system performs the corresponding routine: do open 
(158) ; do prime (162) ; do control (166) ; do status (170) ; 
10 do close (174) . The do prime call (162) is illustrated in 
FIG. 10. The other calls (158, 166, 170, 174) are well 
known in a Macintosh computer system. 

FIG. 12 is a flow chart of an install active 
process detection code routine. This routine involves 
15 performing a patch system task trap (176) , which is 
illustrated in FIG. 6. 

FIG. 13 is a flow chart of an install image 
driver routine. In this routine, the system decrypts a 
driver code from a disk into memory within the computer 18 

2 0 (178) . The image driver is encrypted for security purposes 

so that a user cannot view the driver. The 
encryption/decryption of the driver is typically 
accomplished using the technique explained with reference 
to FIGS. 16A and 16B. The system locks the driver code 
25 into memory (180) . The system then opens the driver (182) . 

FIG. 14 is a flow chart of an open driver 
routine. In this routine, the system sets up an 
interprocess communication vectors (184) , which instructs 
the system where to locate global data. 

3 0 FIG. 15 is a flow chart of a sample count manager 

routine. This routine is executed when the user requests a 
sample (186) . The system checks to determine if samples 
are available (188) by checking the sample count files 
within the database. If samples are available, the system 
35 mounts the virtual volume (192) . If the use is on-line, 
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then the system downloads the software packages containing 
encrypted programs to be sampled and usage file and mounts 
the virtual volume (190) . The packages are typically 
compressed for transmission using, for example, Apple 
5 Computer, Inc.'s Cinepak compression scheme at a lossless 
level, and are transmitted using TC/IP protocol. 

The system then determines if the loaded image 
matches the database image (196) for security purposes. If 
the image does not match, the database data is rectified to 

10 that of the image (198) and the virtual volume is closed 

and unmounted (194) in order to maintain the application in 
a locked state. Otherwise, the system checks the redundant 
sample count on the virtual volume to determine if samples 
are available and in particular if a sample count files 

15 have been tampered with (200) . If no samples are 

available, the virtual volume is closed and unmounted 
(220) . Otherwise, the system decrements the sample count 
and launches the application (204) so that the user may 
operate the application to be sampled. 

20 FIG. 16A is a flow chart of a sector encryption/ 

decryption routine. This routine performs encryption of 
the distributed digital information for security purposes 
in order to prevent unauthorized duplication of the 
information. In this routine, the system determines if 

25 encryption or decryption is required (206) . The system 
then performs the appropriate decryption (208) or 
encryption (210) function. FIG. 16B is a flow chart of a 
preferred varying positional key encryption/decryption 
routine used with the routine of FIG. 16A. The routine in 

3 0 FIG. 16B performs the actual encryption/decryption of data 
and is an example of how to encrypt /decrypt the encrypted 
packages 62 and 68 (see FIG. 4A) which contain the 
distributed software programs or digital information and 
usage files. Other encryption schemes are possible. The 

3 5 significance of the encryption scheme is in providing 
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protection of the distributed information so that one may 
not obtain an unauthorized copy of the information without 
considerable time, effort, and processing capability. 

The encrypt ion/decrypt ion routine of FIG. 16B 
5 uses a varying key based on byte position, also referred to 
as a positional variant. The system determines if sector 
encryption/decryption is required (201) . If it is, the 
system decrypts the first 512 byte block (203) and then 
executes loops, as determined by steps 205, 207, 213, and 

10 215, in order to encrypt /decrypt each byte in a series a 
512 byte blocks. The encrypt ion/decrypt ion of each byte 
involves first at step 209 a permutation to determine a key 
with the key = log (position MODULO 512) X $23FEC3 92 , and 
then at step 211 applying the key to the byte with an XOR 

15 operation. 

FIG. 17 is a flow chart of a setup sample counter 
routine. The system checks the boot block flags (212) and 
checks status of sample count files (214) . This involves 
writing predetermined codes to spare boot blocks of the 

2 0 computer in order to mark the database to identify the 

execution of a software or digital information distribution 
system. Accordingly, these codes written to the boot 
blocks provide an indication that a distribution 
application has been run before on this particular 
25 computer. 

This system for storing a code within an 
operating system of a computer in order to identify whether 
the computer has executed a particular software program 
typically includes the following features. It receives an 

3 0 indication that the computer has executed the software 

program, and searches a non-volatile memory in which the 
operating system for the computer is stored in order to 
locate spare memory locations within the non-volatile 
memory. A code is written to at least one of the spare 
3 5 memory locations, and the code provides an indication that 
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the computer has executed the software program. The code 
is associates with the software program to provide the 
indication. 



5 determines if the sample counter system has been set up 
before on this particular computer (216) . If it has been 
set up before, the system determines if all three sample 
count files are new (218) and if they are, it executes the 
following steps: fill new files with the value "one" at 

10 each location (200) ; write file creation dates to boot 
blocks (224) ; and write file check sums to boot blocks 
(226) . When the sample count files are initialized the 
first time the system is executed, the value "one" is 
written to the files in order to signal that the files are 

15 secure and the system can, therefore, write sample count 

values to the files. Otherwise, the system fills new files 
with the value "minus one" at each location within the boot 
blocks (222) . The "minus one" value indicates to the 
system that the corresponding sample count file has been 

2 0 tampered with or is otherwise corrupted or not secure. 

Accordingly, the system checks the other sample count files 
in order to verify there security. If all sample count 
files have a value of "minus one, " this condition indicates 
that all. sample count files have been corrupted and the 
25 user is not allowed no more samples. If less than all 
sample count files have a value of "minus one," then the 
system can reconstruct the corrupted files using a value in 
the secure or non-corrupted sample count file. The system 
also preferably verifies the sample count information in 

3 0 the invisible files against the information in the usage 



FIG. 18 is a flow chart of a watchdog task 
routine. This is a VBL task, meaning it runs every time 
there is a vertical blanking interrupt. For most monitors, 
3 5 that is approximately 72 times per second. The routine has 

19 



In the routine shown in FIG. 17, the system 



file. 



# # 

three functions. It performs a check to determine if the 
sample application has timed out, and sets a flag 
accordingly. It tests to determine if it may allow the 
driver read, and updates a flag with the current time to be 
5 checked by the driver. It also encrypts and decrypts 

sample counts that are being written/to and read/from the 
sample count files. It performs this encryption in 
multiple phases, simulating an asynchronous process. What 
this does is make it very difficult for a user to determine 

10 where the encryption/decryption is being performed. 

In the routine, the system checks for an 
application time out (228) . It then determines if it is 
"OK" for the driver to read (230) . If it is, it sets a 
flag to a current time (234) . Otherwise, it sets a flag to 

15 zero (232) . The system then determines if a sample count 
requires encryption (236) . If it requires encryption, the 
system performs a phase of sample count encryption (238) . 
Otherwise, the system determines if a sample count reads 
decryption (240) , and if so, .the system performs a phase of 

20 sample count decryption (242) . 

This phase encryption/decryption scheme is a 
subset of the sample count manage routine and works as 
follows. At various times, the distribution application 
needs to determine how many samples of a particular 

25 application remain. At these times, the distribution 

application reads an encrypted string from the invisible 
files. It then takes this information, transfers the 
information into global memory, signals to the watchdog 
task that a count needs decryption, and then places itself 

3 0 into a seemingly endless loop. The watchdog task, having 
been signalled to begin, decrypts the count in three phases 
to ensure that the full algorithm is never directly viewed 
by a user. On each pass, the watchdog task performs an XOR 
and bit rotation and then increments the phase count. The 

3 5 next time the watchdog task executes, if there is still 

20 
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more work to be done, it executes another encryption phase. 
If not, it signals the application that encryption is now 
finished. The distribution application then exits the 
infinite loop and memory contains the correct sample count. 
5 FIG. 19 is a flow chart of a purchase routine for 

allowing users to purchase sampled software programs. This 
routine is executed when a user requests to purchase a 
program or digital information (243) . The system can 
unlock software programs or digital information in response 

10 to a request to purchase the software program or digital 
information. The system can optionally verify purchase 
information, such as a credit card number, before executing 
an unlocking process. 

The system typically checks if the application 

15 has previously been purchased (244) . If it has been 

purchased previously, the system checks to determine if 
this purchase request is an archive install (248) . If it 
is an archive install, the system installs the application 
(254) . For a regular purchase, the system generates or 

20 retrieves a serial number or key code (246) used for 

calculating a password to unlock the program. This serial 
number or key code is typically provided in a purchase 
dialog or window when the user selects the purchase key 48 
(see FIG. 3) . The purchase window also includes an area 

25 for a user to enter the password. The key code and 

corresponding password, as explained below, are preferably 
dynamically generated when the user opens the purchase 
window such that a new key code and password are generated 
each time the user opens the purchase window. In addition, 

3 0 the password preferably only exists in memory, and only as 
long as the user has a purchase dialog or window open. 
These features provide additional security by dynamically 
changing the key code and password. 

If the use is on-line, the system preferably 

35 automatically registers the application with a vendor and 
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then unlocks the application or digital information (250) 
through the on-line connection with the distribution 
center. 

Otherwise, the system can manually register the 
5 application with the vendor and provide a user with the 
password for unlocking the application or digital 
information (252) . The manual registration typically 
occurs with the user calling up a distribution center and 
providing them with the serial number or key code as 

10 provided in a purchase dialog and possibly other 

information such as a credit card number. The distribution 
center in response provides the user with a password used 
for unlocking the application, and the user may then 
manually enter the password in the purchase window. 

15 Accordingly, steps 250 and 252 also involve generating the 
password from the serial number or key code. The serial 
number or key code provided by the user is processed using 
an identical decoding function, explained below, as on the 
user's machine, generating the same password that is stored 

20 in memory on the user's machine. The entered password is 
compared with the one stored in memory. If they match, the 
purchase is completed. 

Accordingly, if the correct password is entered, 
either manually or automatically, the system proceeds to 

25 install the application or digital information (254) . If 
the wrong password was entered, such as in the manual 
unlocking, then the system "returns" and does not unlock 
the application or digital information. 

The installation typically occurs by decrypting a 

3 0 copy of the application or digital information and copying 
the unlocked application or digital information to a hard 
drive or other storage medium on the user's computer. The 
decryption is typically accomplished by copying the 
application or digital information via a pipeline from its 

35 current location in memory to a new (non-reserved) portion 




of the user's hard disk drive or other storage medium which 
is outside of the partition reserved by a software or 
digital information distribution system. While the 
application or digital information is copied to the non- 
5 reserved portion, it is typically decrypted by using the 
technique explained with reference to FIGS. 16A and 16B. 
Accordingly, after this unlocking routine is complete, a 
locked copy of the application or digital information 
remains within the reserved partition and an unlocked copy 

10 of the application or digital information resides on the 
user's hard disk drive or some other storage medium. The 
unlocking and installation may occur simultaneously. In 
addition, while software programs typically require 
installation to run, other types of digital information may 

15 require only unlocking. 

After the application is purchased, a user 
preferably has full use of the program or digital 
information. A vendor or distribution center may mail 
manuals or any other documentation for the purchased 

2 0 program to the user who purchased the program. 

Alternatively, the manuals and documentation may be 
distributed with the program and maintained in a locked 
state with the program. When a user purchases the program, 
the manuals and documentation may then also be unlocked so 
25 that the user can view them electronically or produce a 
hard copy using a computer printer. 

FIG. 20 is a flow chart of a process for a self- 
launching and on-line self -launching software or digital 
information distribution system. A self -launching system 

3 0 has the advantage of not requiring a separate browser for 

distribution and/or sampling of applications or digital 
information. The operation of"" the system is thus 
essentially invisible to the user, since the system 
preferably "appears" to the user as an application or 
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digital information and launches itself when a user selects 
the application or digital information. 



demonstrating applications typically includes the following 
5 features . The system is attached to a software program 
such as in one file as described above. The system 
maintains the software program in a locked state in order 
to prevent unauthorized duplication of the software 
program, such as with encryption and a package file system 

10 described above. When a user selects the software program, 
the system launches itself and can enable the software 
program for execution by the user and allow the user to 
subsequently sample the software program. The system 
maintains the software program in the locked state during 

15 the sampling of the software program in order to prevent 
unauthorized duplication of the software program, and 
selectively disables the sampling of the software program. 



applications or digital information typically includes the 
20 following features. The system is attached to an 

application or digital information such as in one file as 
described above. The system maintains the application or 
digital information in a locked state in order to prevent 
unauthorized duplication, such as with encryption and a 
25 package file system described above. When a user selects 
the application or digital information, the system launches 
itself and can unlock the application or digital 
information in response to a purchase request. 



30 software or digital information distribution sy stems 

preferably use the processing described above in addition 
to the steps shown in FIG. 20. In order to sample an 
application, a user in a self -launching system typically 
selects an application (256) . This may occur by, for 

3 5 example, "double clicking" on an icon displayed on a 



Accordi ng, a self -launching system for 



A self -launching system for distributing 



Self -launching and on-line self -launching 
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display device and corresponding to the application. In 
the self -launching system, therefore, the applications 
typically appear to the user as executable programs even 
though they are locked and may only be sampled by the user 
5 or purchased upon providing the required information. 

After the user selects the application to sample, the code 
for the distribution application executes (258) . If the 
use is on-line, the software package described above is 
first downloaded (257) before executing. The software 

10 package is typically one file (see FIG. 4A) which includes 
a distribution application and an encrypted package and is 
thus transmitted for on-line use as one file. The 
encryption is typically accomplished using the technique 
described with reference to FIGS. 16A and 16B. The 

15 encryption protects the software programs or digital 

information during transmission. This file is typically 
compression for transmission using, for example, Apple 
Computer, Inc.'s Cinepak compression scheme at a lossless 
level, and is transmitted using TC/IP protocol. 

20 The system then, as described above, checks to 

determine if all samples have been used (260) . If samples 
are remaining, the system code mounts a data fork of file 
as the virtual volume (262) and decrements the usage count 
and the files in the virtual volume (264) . The system then 

25 proceeds with the processing described in the other flow 
charts provided in the present specification. 

If the self -launching system involves 
distribution of digital information without allowing 
sampling, then the system typically checks to determine if 

30 the information has been purchased (259) . If is has been 
purchased, then the system executes step 262 and bypasses 
step 264, since samples are not available. If the 
information has not been purchased, then the system 
typically checks to determine if the user wants to purchase 

35 the information (261) . If the system receives a purchase 




request, then it executes a purchase routine 263 (see FIG. 
19) . 

FIG. 21 is a flow chart of a process for 
generating a serial number which contains identification of 
5 marketing information for software programs. The system 
retrieves the raw data from a sample count files (266) , 
which includes an identification of how many times a user 
sampled each application. The system then calculates 
marketing statistics and formats such information into a 

10 series of bytes (268) . This step may involve, for example, 
the following: determining the total number of samples 
used (270) ; determining how many times each application was 
sampled (272) ; determining a most frequently sampled 
application (274) ; determining a category of a most 

15 frequently sampled program (276) ; determining which version 
of particular applications a user has sampled (277) ; or 
other statistics to be determined, for example, by a 
distributor (278) . Other statistics may include, for 
example, statistics related to time duration of the 

20 samples, such as an average time duration of sampling, 

which may be obtained using a computer's internal clock and 
timing each sample. Examples of categories of software 
programs include, but are not limited to: business 
software, games, financial management programs, and 

25 educational programs. A vendor or distributor may also 
create their own categories and electronically associate 
programs with those categories. 

Gathering these statistics provides for many 
advantages and value in distributing programs to be 

3 0 sampled. For example, it allows vendors to identify 
programs which are not popular and replace them with 
programs which have a higher sales rate. It also allows 
vendors to identify the most popular programs and include 
more programs for sale in the same categories. Identifying 

35 a category of a user's most frequently sampled program also 
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allows vendors to market additional similar products to 
that particular user and thus increase the likelihood that 
the user will purchase more software from the vendor. For 
example, when the user calls the vendor to purchase a 
5 program, the vendor can quickly identify the most 

frequently sampled program category by decoding the code 
(serial number) of the purchased program. The vendor could 
then immediately offer any additional programs for sale 
which are in the same category and perhaps "on sale" or 

10 subject to a discount. 

Given the information provided by the sample 
count files , the information for the marketing statistics 
can be determined with simple calculations. The sample 
count files contain an identification of each application 

15 and the number of samples remaining for the corresponding 
application. Therefore, by knowing how many samples were 
originally available, the system can determine the number 
of samples used for each application by samples remaining 
from the original number of allowed samples. The system 

20 can add up the number of samples used to determine a total 
number of samples used. Other statistics can be calculated 
in a similar manner using the information in the sample 
count files and possibly other information such as 
categories of sampled applications. 

25 A distributor may determine that other statistics 

are desired and the system would then execute additional 
steps as part of step 268, as mentioned above. The system 
determines if more statistics are required (279) . The 
system continues to execute steps for determining 

30 statistics until such processing is complete. As the 

system gathers and calculates the marketing statistics, it 
typically concatenates the resulting bytes, resulting in a 
series of bytes with byte representing a statistic. The 
system electronically associates each byte position with a 

35 statistic so that, by knowing a particular byte position, 
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the system can decode the byte and produce the resulting 
statistic. The system then converts the series of bytes 
determine that step 268 into an ASCII serial number (280) . 
Table 1 provides an example of a file for associating byte 
5 positions with statistics . 

Table 1 

byte 

10 position statistic 

1 total number of samples 

2 number of application #1 samples 

3 number of application #2 samples 

4 most frequently sampled category 

N other statistic 



Appendix A provides an example of a source code 

2 0 listing in C programming language for converting the series 

of bytes determined in the processing shown in FIG. 21, and 
optionally other information, into a key code and password 
for use in unlocking the application or digital 
information. The code shown in Appendix A generates both a 
25 key code and password using the marketing information 

(series of bytes described above) and the current date and 
time. The code shown in Appendix A can thus also be used 
to decode the key code and extract the series of bytes 
containing the marketing information. The key code is 

3 0 displayed to the user and in the purchase window and is 

what the user provides to a distribution center to obtain 
the password. This password is then used to unlock the 
application or digital information, as described above. 
FIG. 22 is a flow chart of a process for 
35 automatic sale of software programs. One or more software 
programs, each in a locked state such as with the 
techniques described above, are stored in a computer 
database or available on-line. When one wants to purchase 
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one or more of the programs, the system in response to the 
purchase request unlocks a copy of the program and 
maintains a record of how many copies were sold. An 
example of a use for this system is where a company 
5 routinely purchases additional copies of software programs 
such as when new employees are hired. 

Accordingly, this system for automatic sales of 
software programs typically includes the following 
features. It accesses a software program within a computer 

10 database and maintains the software program in a locked 
state in order to prevent unauthorized duplication of the 
software program. In response to a request to purchase the 
software program, the system unlocks a copy of the software 
program and distributes the unlocked copy. The system also 

15 records how many copies of the software program have been 
distributed in response to the requests to purchase the 
software program. 

As shown in FIG. 22 , the system typically 
displays an indication of locked applications available for 

20 purchase by a user (292) . If the use is on-line, the 
system downloads encrypted software packages containing 
programs and usage file (293) . The encryption is typically 
accomplished using the technique described with reference 
to FIGS. 16A and 16B. The packages are typically 

25 compressed for transmission using, for example, Apple 

Computer, Inc.'s Cinepak compression scheme at a lossless 
level, and are transmitted using TC/IP protocol. If a user 
requests to sample a particular application (294) , the 
system executes sample routines (296) . The sample routines 

3 0 may be, for example, the routines described in the present 
specification. If the system receives a request to 
purchase an application (298) , it preferably performs the 
following steps. The application is registered with a 
vendor and unlocked (300) . A serial number is then 

35 optionally assigned to the purchased application (302) . 
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The application is distributed and installed (304) . Then 
the system updates a sales record and issues an invoice 
(306) in order to record the application purchased and how 
many copies have been purchased. The step 3 00 may be 
5 implemented as described in the other routines in the 
present specification . 

While the present invention has been described in 
connection with a preferred embodiment thereof, it will be 
understood that many modifications will be readily apparent 
10 to those skilled in the art, and this application is 

intended to cover any adaptations or variations thereof. 
It is manifestly intended that this invention be limited 
only by the claims and equivalents thereof. 
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void CDolphinApp: :DoPur chase () 

CSampleApp *theApp; 
const short okltem = 1; 
const short cancelltem = 2; 

unsigned long tempi = qd.randSeed; 
unsigned long temp3; 

GetDateTime (&temp3) ; 

temp3 = temp3 & 0x00000065; 

temp3 = temp3 >> 2; 

unsigned long tempo = *( (long*) 0x0146) ; 
temp3 = temp3 & 0x2 F; 

// ROL.L temp3, tempo 

long a = tempo << temp3 ; 

long b = tempo >> (32 - temp3) ; 

tempo = a | b; 

GetDateTime (&temp3) ; 
tempi = temp3 * tempi; 

a = temp3 << 7; 
b = temp3 >> (32 - 7) ; 

tempO = a | b; S 
temp3 = tempo ^ temp3 ; ^< 



gd.randSeed = ,temp 0; 

temp3 = temp3 & Ox^rQuOOOOE; 

long keyCode = 0; 

for (short r = 0; r < temp3 ; r++) 
keyCode = Random ( ) ; 

CStr255 usageCode; 



unsigned long installedDate = gUsagelnfo.GetlnstalledDate 
("Dolphin Prefere 
installedDate -= 0xA81B3480; 
installedDate = installedDate / Ox00093A80; 

CStr255 instWkStr; 

CodeNumber (installedDate, 2 , instWkStr) ; 

long numOf ProgsSampled = gUsagelnf o . GetTotalAppsSampled () 
CStr255 numProgsSampledStr ; 

CodeNumber (numOf ProgsSampled, 2 , numProgsSampledStr) ; 
TopSampleA top5; 

gUsagelnfo.GetTopSSampledApps (top5) ; 

CStr255 numlAppStr; 

CStr255 num2AppStr; 

CodeNumber ( top5 [0] , 2 , numlAppStr) ; 

CodeNumber (top5 [1] , 2 , num2AppStr) ; 

long totalSamples = gUsagelnfo.GetTotalNumOf Samples {) ; 




{ 
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C?Str255 totalSamplesStr; 
*^Cc5ueNumJDer (totalSamples, 2 , totalSamplesStr) ; 

usageCode = instWk;Str + _ 

numProgsSampledStr + 
numlAppStr + 
num2AppStr + 
totalSamplesStr ; 

} 

CStr255 programNumStr; 

CodeNumber (f SelectedAppID, 3, programNumStr); 
CStr255 keyCodeStr; 

CodeNumbe r ( keyCode , 4 , keyCode S t r ) ; 
CStr2 55 target Password = deecode (keyCodeStr) ; 
keyCodeStr = programNumStr + CStr255( M - n ) + keyCodeStr; 
if ((itemHit == okltem) && 

(IUEqualString (password, purchaseBackDoor) == 0) ) 
theApp- >SetTo Pur chased () ; 
CRect upperLef tRect (0,0,150,60) ; 
InvalRect (upperLef tRect) ; 
InstallApp () ; 

if ((itemHit ==okItem) && 

(IUEqualString (password, unPurchaseBackDoor) == 0 
theApp- >SetToUnPurchased() ; 
CRect upperLef tRect (0,0, 150, 60) ; 
InvalRect (upperLef tRect) ; 

} 

} else { 

SysBeep (1) ; 
SysBeep (1) ; 



void CodeNumber (long number, short digits, CStr255& theString) 

{ 

long temp2 ; 

theString [0] = digits; 

for (short index = digits; index > 0; index--) { 
temp2 = number; 
temp2 = temp2 & OxOOOOOOlF; 
temp2 += 65; 
if (temp2 >= 'Z') 

temp2 - = 41; 
theString [index] = temp2 ; 
number = number >> 5 ; 

} 

if (number > 0) 

theString [1] = 42; 
} ' 

CStr255 deecode (const CStr255& input) 

char output [7] ; 
char stg [2] ; 





int msg_number; 

int bl, Bl, xx, len, retcode; 

long code, bin; 

len = input. Length (); 

code = 0; 

for (xx = 1; xx < 5; xx++) 
{ 

Bl = 0; 

sprintf(stg, "%d", input [xx] ); 

bl=atoi ( stg ) ; 

if (bl > 64 && bl < 91) 

Bl = bl - 65; 
if (bl > 49 && bl < 56) 

Bl = bl - 24; 

switch (xx) 

{ 

case 1: 

code+= Bl * 32768 
break; 

case 2 : 

code+= Bl * 1024; 
break ; 

case 3 : 

code+= Bl * 32; 
break ; 

case 4 : 

code+= Bl; 
break; 

default : 

break; 



code = (code A 43605) * 1523; 



for (xx = 0; xx < 6; xx++) 

{ 

switch (xx) 

{ 

case 0: 

bin = 33554432; 
break ; 

case 1: 

bin = 1048576; 
break ; 

case 2 : 

bin = 32768; 
break ; 

case 3: 

bin - 1024; 
break ; 

case 4 : 

bin = 32; 
break ; 

case 5: 

bin = 1; 
break ; 

default : 
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^ break; 
if (code >= bin) 

{ 

Bl = code / bin; 
code-=Bl * bin; 
if (Bl + 65 <= 90) 
{ 



} 

else 

{ 
} 



} 

else 
{ 

} 



bl = 65; 



bl = Bl + 65; 



bl = Bl + 24; 



sprint f (&output [xx] , "%c" , bl) ; 
output [6] = ' \0' ; 

return (CStr255 (output) ) ; 



} 



#pragma segment Main 

long intcode (const CStr255& input) 

char stg [2] ; 
int msg_number; 

long bl, Bl, xx, len, ret code, code; 
len = input . Length () ; 
code = 0; 

for (xx = 0; xx < 4; xx++) { 
Bl = 0; 

sprintf(stg, "%d n , input [xx] ); 

bl=atoi ( stg ) ; 

if (bl > 64 USc bl < 91) 

Bl = bl - 65; 
if (bl > 49 && bl < 56) 

Bl = bl - 24; 

switch (xx) 

{ 

case 0: 



case 1 : 



case 2 : 



case 3 : 



code+= Bl * 32768 
break; 

code+= Bl * 1024; 
break; 

code+= Bl * 32; 
break; 

code += Bl; 
break ; 
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default: 

break ; 

return (code) ) ; 

} 
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